Do the integration-tests rely on the unit-tests somehow?

I don't think so :)

@andistorm Do you know a solution for this? Otherwise, I would just set it to main for now.

I would suggest to not checkout the ci repo in the workflow, but to use custom github actions. There are multiple options for github actions: composite actions that are similiar to reusable workflows, Javascript actions and Docker container actions. The last one would be an option to include additional filesto the action.

I could also imagine a solution with having the bash scripts in each repo with "custom" commands and cmake flags..

This doesn't seem like the right way to set up a reusable workflow. When someone makes a fork, the CI instructions on their forked branches will point to whatever original repository is passed in, for example, EVerest/libocpp. What should happen is that the current branch that initialized the workflow should run, fetching the branch from the forked repository.

In the current state, this fails at the checkout stage because we can't check out the original repository from our fork.

I don't see the problem in the way the reusable workflow is implemented, but the way it is called.

In the example of libocpp the parameter repository: EVerest/libocpp is used. You adapted it similiar in your example with repository: EVerest/libfsm

To enable workflows running on forks I suggest the use of the env variables
.

-> In both examples I would replace the line with repository: ${{ github.repository }}.

Shouldn't the reusable workflow use that by default?

yeah, maybe this parameter is obsolete, not sure about this.. I will spend some time on this in the next weeks to figure those things out